Decision making and implementation system

ABSTRACT

Systems for assisting a user in a process of decision-making or analysis involving a topic comprising a computer and one or more computer applications comprising: a module for displaying a screen set soliciting a set of input data, and inputting said set of input data, wherein at least some of the data is characterized with a value representing a degree of certainty regarding the data; and a module for displaying a screen or screen set showing a current recommendation or analysis where the degree of certainty regarding the input data is reflected in the recommendation, calculations, or output; wherein said module optionally provides information or links to modify those inputs which are determined to have one or more of: the highest importance, the greatest effect on the calculated certainty of the current recommendation or analysis, and the greatest effect on the calculated certainty of a particular calculated result.

CROSS REFERENCE

This application is a continuation of pending U.S. application Ser. No. 13/095,780 filed Apr. 27, 2011, which is a continuation of U.S. application Ser. No. 12/123,388 filed May 19, 2008 (now U.S. Pat. No. 8,095,404), which is a continuation of U.S. application Ser. No. 09/811,311 filed Mar. 16, 2001 (now U.S. Pat. No. 7,376,576), each of which are hereby incorporated herein by reference in their entirety.

FIELD OF THE INVENTION

This invention relates to the field of logic systems and devices for assisting in the making of decisions or otherwise weighing alternatives in complex factual scenarios. The system and devices also are useful in preparing and implementing plans for complex analysis. The invention has applicability in, among other areas, analysis and decision-making in business settings such as due diligence or structuring conducted in connection with a business transaction, or considering and implementing employee-retention systems. The invention may also be used in any other setting requiring logical analysis of complex systems, such as science and medicine.

BACKGROUND OF THE INVENTION

Decision-making and analysis in business, as well as in other fields, has traditionally been conducted in an ad-hoc manner. In the business setting, a decision-maker such as an executive in finance or business development or some other manager gathered facts he deemed material to the decision and employed in-house advisors or referred to outside expert consultants. Alternatives were discussed and weighed, and decisions were made.

Such an approach can be flawed in several ways. Because the approach is not systemized, the decision may be made without a complete and accurate collection of important factual data. In other words, there may not be a “checklist” for ensuring that all of the desired facts are input into the decision-making process. As a result, facts that should be weighed are not, and it is even possible that facts that should not be weighed are. For example, outside expert consultants especially will make assumptions about the goals that the decision-making process seeks to achieve or even about the applicable factual setting. These assumptions, based largely on the outside expert consultant's experience, may not be accurate in all cases. Moreover, the outside expert consultant may be so ingrained with his past experience that he may make these assumptions without even being aware of doing so.

The quality of both in-house advisors and outside expert consultants varies widely. Even the established professional service firms such as large accounting firms, law firms and management consultant firms that have well-deserved reputations for quality and creativity, occasionally rely too heavily on relatively junior and inexperienced people. The lesser known firms include highly-competent professionals along with less-competent individuals. In-house advisors tend to know the company business quite well in comparison to outside expert consultants, and are therefore less prone to factual mistakes, but often are not steeped in the area that is the subject of an important decision; for example, an in-house advisor usually does not analyze sizeable mergers of his company on a day-to-day basis.

The decision-making process and analysis that is traditionally employed does not document the process well. Because the systems tend to be experiential and intuitive, there is little record of why a decision was made or the facts upon which it was based. This is particularly problematic if the decision is later challenged by shareholders or others.

In addition to all the flaws, outside expert consultants are usually quite expensive. It has been estimated that in the United States alone businesses spend over $200 billion annually on consultants, lawyers, accountants and other specialty advisors. As noted above, some of this money may be spent for services that are often misdirected, often not delivered on a sufficiently timely basis, occasionally incompetent, and usually poorly documented.

There have been attempts at developing more systematic and documented routines for decision-making using modern computer techniques and databases. So-called “business intelligence software providers” such as Hyperion Solutions, Microstrategy and Cognos offer software designed to front-end with existing user databases and ERP systems. This software mines information residing elsewhere in the user's organization to provide managers with real-time operational statistics such as amount in inventory and daily sales figures. Such software, however, is not especially designed for the decision-making process, but rather for quick access to rapidly changing information about the user's organization.

Another source of information and decision support services is management education providers and the executive-training centers at many of the college and university business schools. These organizations issue reports, present conferences and provide training to disseminate management “best practices.” This is a highly fragmented industry with a largely ad hoc approach which seldom offers a saleable and scaleable product for systemized decision-making.

Business information providers such as Bloomberg, Gartner Group, Forester and Hoovers provide both synthesized and unsynthesized business information. The expertise of these groups is usually specific to particular industries (such as technology in the cases of Gartner and Forester) or specific to particular kinds of information (such as debt and credit ratings in the case of Standard & Poor's. These organizations have a high degree of expertise in their developed fields of information, but do not offer wide ranging products that systemize the decision-making process for general application.

It can be appreciated that there is a need for a system that takes advantage of the sizeable databases available in, and the high processing capability of, modern numeric processing equipment to deliver decision support and implementation. Such a system should ideally produce sound recommendations based on considered analysis utilizing flexible databases containing extensive information. In a preferred embodiment, such a system would be interactive with and tailored to the specific needs and circumstances of each user, and would document for later retrieval the analysis made, the outcome, and the input facts relied upon.

In addition, such a system would ideally take advantage of large private and public networks such as the Internet. The use of the Internet would allow near-universal access and a concurrent presentation platform and user interface, and also allow the system to draw on the vast information content available on world-wide Internet servers. Finally, such a system ideally would take advantage of the expertise and goodwill held by existing professional service and consulting firms.

SUMMARY OF THE INVENTION

The present invention addresses these and other shortcomings in the prior art. In a preferred embodiment, the invention is presented as a set of Internet-based decision-support tools in an application service provider (“ASP”) format, but may also be presented in other formats that are not ASP-related or do not utilize the Internet, such as by diskettes, CD ROMs or programs downloaded via a public or private network, all as discussed in greater detail below.

The system can be used in a variety of decision-support and analysis applications, including, without limitation, business applications such as mergers and acquisitions, annual strategic planning, employee relations, due diligence, globalization strategy and implementation, risk management, and compensation. The system is also applicable in analyzing other complex systems, including in science, medicine, engineering.

The invention has several aspects. One aspect involves the methodology of providing expert decision-making support through an easily-accessible network such as the Internet utilizing software that is optimized for the particular field that is the subject of the decision or analysis. The tools are presented in a hierarchy of modules, submodules and pages containing information and requesting data from the user in the manner described below. The owner or licensee of the system realizes revenue on the user's use of the system through a scheme of user subscription fees or per-use fees or a blended fee approach.

Expert assistance in designing the system, and market recognition, is achieved, in part, by cooperative arrangements with well-known professional service or consulting firms. These firms benefit from the exposure they receive in being associated with the product and from client referrals via the product. They may also receive fees for their services in the form of traditional hourly fees, fees based on the extent of use of the particular product with which their name is associated, fees per unit of time (such as fixed monthly fees) or any combination of the foregoing. In an Internet implementation, the website presenting the system can be hyperlinked to other websites including those of the professional service and consulting firms involved in developing the system. The system also tracks the use of the materials developed by the professional service and consulting firms and provides such tracking information to those firms for their marketing and business use.

One function of the system is to frame complex tasks and issues, and to organize and implement decisions faster and more effectively using decision modules. At the same time, the system archives electronically the flow of decision-making for future reference. A second function is to allow product managers operating in the organization that owns or leases the system to interact with outside experts efficiently and to create new decision-making modules and to update existing modules.

The kinds of decision-support modules in the system include general modules with applicability for a wide range of decision support; industry-specific modules for ascertaining data specific to particular industries and with input inquiries directed toward those industries; products that are created especially for a particular company or division of a company; and modules that are customized for several companies or groups of companies. These kinds of modules, and the several modules within each kind, share certain logical frameworks or architectures summarized below and described in greater detail under the heading, “Detailed Description of a Preferred Embodiment.”

The base unit in the logical framework is a module itself. A module is a set of interrelated content with a defined purpose. Each module may be a “submodule” in relation to a module that is in a higher level of the hierarchy; and each module may have submodules in relation to it. A characteristic of modules, whether or not they have submodule status in relation to other modules or have other modules that are submodules in relation them, is that they output a discrete decision or analysis with respect to their subject matter. In addition, they have associated information such as bywords, date of creation or update, and a grouping of page hierarchy. A module may also have or include branding or URLs of companies or firms that contributed to its creation or maintenance, and biographical information for experts.

A page is the basic individual unit of presentation of information within a module. Pages are grouped into sections of one or more pages and each section has a priority. Like modules, sections may contain several other sections which are subsections in relation to the sections in which they are contained. Each section is assigned a priority number. When the system navigates into a section, the priority number of the sections at the same level are noted, and the section with the highest priority level is navigated to next.

Each page includes a number of attributes. One is the page precondition which specifies a formula or other terms and the conditions under which a client is allowed to access the page. These conditions may be, for example, suitable answers to specific queries posed to the client which establish the page's applicability. The outcome of a condition formula must be binary, i.e., yes or no, so that the page is either presented or not presented.

The page priority is a number applicable to the data elements on the page. This priority applied to the data elements is used in the maximum impact procedure and the calculated importance procedure described below, but does not affect client navigation. In a preferred embodiment, numeric priority ranges from 1 to 100, but any range scheme may be used.

The page is typically broken into a useable number of separate paragraphs. Each paragraph is identifiable by an associated header, the text of the paragraph, and data elements or Formulae if applicable. Paragraphs may also include predefined icons in the margin that suggest the content of the associated text (sometimes referred to as “emoticons”).

The pages also include names which label each page in the page hierarchy, headers to briefly describe the page contents to a user, visited indicia to record client visits to the page (which may or may not be displayed), a text element called “notes” which the client can use to record his user notes pertaining to the page, and a list of attachments which are files available for download from the page. Also on the page in a preferred embodiment may be indicia for “done” and “results.” The “done” indicia indicates that all information sought from the user has been input. The “results” indicia indicates that the results that the system has determined are now available for a server module or section.

Also in a module, along with pages, are data elements. These are the basic units for storing client information, and are catalogued according to the module in which they are entered. Each data unit has the attributes of name, descriptor, source, (either input or calculated), cardinality, value type, text of the question associated with the data, value, value default, the level of certainty associated with the data, expressed as a unit in a range, choice, Minimum and Maximum, numeric range, formulae for the calculated data elements, and priority for use in the maximum impact procedure and the calculated importance procedure. The nature of some of these attributes may not be apparent from their names. Cardinality refers to the number of values that a data element may have. Although most data elements may have only one value, such as a number, others may have several values, such as context information. Value type refers to the actual data type for the data element; it may be a Boolean operator, a number, a choice, text or of other types. Choice refers to the set of possible choices associated with a data element. Minimum and maximum are the defined bounds for a numeric data element; for example, a data element representing the number of employees of a company could have a minimum of zero but could not have a minimum equal to a negative number. The numeric range refers to the range bounded by the minimum and maximum values.

The data elements also include an attributed context describing membership and constraints on usage. Regarding membership, the context indicates the potential usage of the data elements. For example, formulae applicable for potential merger partners may be specified for the context of an individual company that is a potential merger partner or for a group of “merger partners.” Regarding constraint or usage, the context may limit the applicability of the data element. For example, a data element “revenues” with a context of 1998 would not normally be applicable to the year 1999.

Finally, the modules may include formulae that perform operations on data elements. The formulae can utilize logical clauses such as AND/OR, or =, and operators such as, −, *, / in the case of numeric data elements. Functions are defined to perform special operations too; for example, the function xyplot (title, x, y) can be used to generate a graphic element showing x as a function of y. Other special functions are described under “Detailed Description of a Preferred Embodiment” below.

One of the important aspects of the present invention is the ability to focus in on a topic and a recommendation incrementally. In prior art systems, the approach is typically to input the information necessary to make a decision, process that information in accordance with some predetermined algorithm, and output the result. This approach is unresponsive to the desires of the users to obtain a particular outcome, because it simply gives an answer without revealing the reasoning behind that answer. Further, it wastes user time and processor power by completely processing the matter even if the user is interested in only a preliminary conclusion or a portion of the answer.

The present system asks for the necessary information a portion at a time, processes that portion, outputs the result, and then goes to another portion. The user is thus free to abort the process when it takes a route that is undesirable, is incompatible with the final desired conclusions, or is simply sufficiently detailed for the present purposes without going further. This approach also enables the user better to see the logic at work in arriving of the conclusions, in order to experiment with alternative input information to arrive at the desired conclusions.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features of the invention are set forth with particularity in the appended claims. A better understanding of the features and advantages of the present invention will be obtained by reference to the following detailed description that sets forth illustrative embodiments, in which the principles of the invention are utilized, and the accompanying drawings of which:

FIGS. 1A and 1B depict a non-limiting example of a page hierarchy for a module for structuring alternatives in a proposed investment, in this case, a hierarchy including submodules addressing: Background and Relevance Check, Lay of the Land/Required Materials, Objectives Assessment, Control Assessment, Consideration; Planned Payment, Measuring Success, and Preliminary Recommendation.

FIG. 2 depicts a non-limiting example of a first substantive page for a user in a module for structuring alternatives in a proposed investment, in this case, a page including paragraphs describing: What this Module Is, What this Module is Not, and Other Modules You Should Have Completed.

FIG. 3 depicts another non-limiting example of an informational page in a module for structuring alternatives in a proposed investment, in this case, a page explaining to the user the manner in which the module operates.

FIG. 4 depicts another non-limiting example of a page in a module for structuring alternatives in a proposed investment, in this case, a first page requesting user data input.

FIG. 5 depicts another non-limiting example of a page in a module for structuring alternatives in a proposed investment, in this case, a page asking for information about the user's desired control over the business or particular assets being acquired.

FIG. 6 depicts another non-limiting example of a page in a module for structuring alternatives in a proposed investment, in this case, a page requesting user data input in the form of a table for the user to enter input data dividing the purchase price into categories for consideration.

FIG. 7 depicts another non-limiting example of a page in a module for structuring alternatives in a proposed investment, in this case, a page requesting user data input in the form of a table eliciting input data about the metrics that the user will use to measure whether the proposed acquisition shall have been successful.

FIGS. 8A, 8B, and 8C depict another non-limiting example of a page in a module for structuring alternatives in a proposed investment, in this case, a page offering preliminary recommendations.

FIGS. 9A and 9B depict a non-limiting example of a page hierarchy for a module for selecting a business combination accounting method, in this case, a hierarchy including submodules addressing: Business Combination Accounting, Required Materials, Initial Questions, Purchase vs. Pooling, Applying the Pooling Method, Pooling Methods Application: Results, Applying the Purchase Method, Purchase Method Application: Results, Appendices: Definitions, Business Combinations: Numerical Example, and Appendices: Recognition of Liabilities in Purchase Accounting.

FIG. 10 depicts a non-limiting example of a page for a user in a module for selecting a business combination accounting method, in this case, a page including paragraphs describing: Background: Purchase vs. Pooling, Purchase Method: Accounting Implications, Pooling Method: Accounting Implications, and New FASB Rulings.

FIG. 11 depicts a non-limiting example of a page for a user in a module for selecting a business combination accounting method, in this case, a page describing the methods required for the section.

FIG. 12 depicts a non-limiting example of a page for a user in a module for selecting a business combination accounting method, in this case, a page inviting responses to two sets of questions designed to obtain facts necessary to the determination whether the proposed transaction constitutes business combination and the determination of the acquiring entity tool.

FIG. 13 depicts a non-limiting example of a page for a user in a module for selecting a business combination accounting method, in this case, a page designed to determine whether the pooling method of accounting is available for the transaction.

FIG. 14 depicts a non-limiting example of a page for a user in a module for selecting a business combination accounting method, in this case, a page displayed if the system determines that pooling is available.

FIG. 15 depicts a non-limiting example of a page for a user in a module for selecting a business combination accounting method, in this case, a page showing pro forma financial statements under pooled accounting.

FIG. 16 depicts a non-limiting example of a page for a user in a module for selecting a business combination accounting method, in this case, a page displayed if the system determines that pooling is not available.

FIG. 17 depicts a non-limiting example of a page for a user in a module for selecting a business combination accounting method, in this case, a page showing the pro forma results of the proposed transaction of the financial statements of the acquiring company using the purchase method of accounting.

FIG. 18 depicts a non-limiting example of a page for a user in a module for selecting a business combination accounting method, in this case, a page devoted to defining several terms used in the module for the convenience of the user.

FIG. 19 depicts a non-limiting example of a page for a user in a module for selecting a business combination accounting method, in this case, a page devoted to an example of the pooling method versus the purchase method of accounting in a hypothetical acquisition.

FIG. 20 depicts a non-limiting example of a page for a user in a module for selecting a business combination accounting method, in this case, a page showing an outline of appendices to the module describing certain additional ramifications of the outcome.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

The invention can be illustrated with examples. It is important to recognize that the invention extends beyond the specific examples, and to the more general use of the hierarchical system and overall organization and methodology, as expressed in the claims below. These examples merely serve to illustrate a use of the invention.

One embodiment involves a module for structuring alternatives in a proposed investment. This module assesses strategic, tactical and operational priorities to generate a preliminary list of potential deal structures. This preliminary list is refined with detailed analysis and additional user input to provide evaluations and recommendations of the several potential structures, the logic behind the recommendations, and a high level quantitative analysis.

FIGS. 1A and 1B show the page hierarchy for the module. In a sense, the page hierarchy is a table of contents; however, it changes dynamically in the manner shown below as the system processes input information. The first substantive page for the user is the “Background and Relevance Check” page, shown in FIG. 2. That page briefly describes the purpose of the module, identifies operators for which the module is intended, and alerts the user that there are certain other modules that the user should have completed prior to undertaking this module (the merger and acquisition module, the target identification module, the due diligence module and the valuation module in this case). In this particular example, these other modules are merely recommended; alternatively, this module could incorporate these other modules as submodules or otherwise require their completion as a precondition to proceeding in this module. The user advances to the next page in the module by clicking on the “Proceed to next page” phase 22.

The next page, shown in FIG. 3, is another informational page, explaining to the user the manner in which the module operates. There are two main phases to the operation of this module. First, a series of questions are posed in order to generate input data. This data is processed in the manner described below to produce a preliminary recommendation of potential deal structures. That preliminary recommendation then is refined and the potential deal structures are narrowed by posing a series of additional questions through other sections or submodules of the module.

This page in FIG. 3 also informs the user of the materials he may wish to have at hand for answering the questions to be posed, and indicates the type of individual who will most likely benefit from, and have sufficient expertise in using, the module, namely a chief financial officer, chief strategy officer, or a comptroller in this particular example. The user advances to the next page by clicking on the “Begin Module Assessments” phrase 23.

The next page, shown in FIG. 4, is the first page of the module to request user data input. The heading 26 “Objectives Assessment” provides a shorthand summary of the page contents. A paragraph 28 bearing a heading 30 of “Background” explains briefly what is being accomplished in the page. In other words, this page asks the user to specify as input data the objectives underlying the proposed insertion. The first step in that process is to input the portions of the business sought to be acquired.

This information is elicited through a table 31 asking yes or no questions, beginning with the question whether it is the “Entire Business” that is sought to be acquired. If the answer is yes, then the answers to the remaining questions in the table which are directed toward whether certain portions of the business are being acquired can be ignored. If the answer to the question whether the entire business is proposed to be acquired is no, then the user goes on to answer the remaining questions in the table about which particular portions of the business are being acquired.

The table 31 also elicits from the user information about the certainty of his answers to the questions, on a scale from 1-5 in this example. This “certainty” information is used by the system in a variety of ways. In some determinations, the degree of certainty directly affects the determination, as is the case when a relatively high degree of certainty is necessary before undertaking a particular kind of transaction or assuming a particular kind of risk. The certainty information is also used in expressing the likelihood that a given recommendation is the correct one; the certainty of the output is thus dependent upon the certainty of the input. This simple syllogism becomes much more complicated when one recognizes that the weight given to the input variables varies with different output recommendation. A relatively low degree of certainty in a given data element may therefore result in a relatively low degree of certainty in the output recommendation for one output recommendation but not for another. The certainty information is dealt with according to logical precepts. For example, input data x may be highly certain and output data y may be highly uncertain. If calculated data element z=x or y, then the certainty of z is highly certain. But if z=xy, then the certainly of z would be highly uncertain.

Similar to certainty information is importance information. A user may consider a particular outcome or recommendation to have a particular degree of importance, or the system itself may be programmed to assign to a particular outcome or recommendation a particular degree of importance. For example, certain tax or accounting treatment for a transaction may be considered important under some circumstances. Notably, such treatment may not be considered important under other circumstances, and the system can be programmed to distinguish between such circumstances. The outcome or recommendation that is assigned a particular degree of importance, like other outcomes or recommendations, is based directly or indirectly on input data, and is presented in a set of one or more display screens. The input data upon which a recommendation with an assigned degree of importance is based is also assigned degrees of importance. The degree of importance assigned to such input data is based on (1) the degree of importance assigned to the recommendation that it helps to determine, and (2) the criticality of such item of input data in making that determination. Some items of input data, for example, will have relatively low degrees of importance even though they are related to recommendations of relatively high degrees of importance, because they play only a small role in determining those recommendations of high degrees of importance, and conversely. The assigned or determined degrees of importance of input data can be used to identify screens for display to the user in presenting the recommendations and ways to change the recommendations.

Another table 32 on this page solicits for input the expected price of the proposed acquisition together with the user's level of certainty with respect to the price that he inputs. This information is also used in subsequent pages. The user advances to the next page by clicking on the “Proceed to next page,” phrase 34 of this page.

The next page, shown in FIG. 5, asks for information about the user's desired control over the business or particular assets being acquired. As in the previous page, there is a page name 36 and a paragraph 38 with a heading 40. The information in this example is elicited through a table 42 setting forth the business portions being acquired and providing a set of four choices for the user: “Unilateral control,” “Shared Control,” “Influence” or “No Control (passive).” The user checks a box in each row for each business portion proposed to be acquired. The user can then advance to the next page by clicking on the phrase 46, “Proceed to next page.”

The relationship between the page in FIG. 5 and the page in FIG. 4 is one of precondition. That is, the information sought in FIG. 4 must be entered before the information sought in FIG. 5 can be entered. The system logic thus will not advance the user from the page of FIG. 4 to the page of FIG. 5 until the page of FIG. 4 information is indeed entered. If the user seeks to advance from the page of FIG. 4 to the page of FIG. 5 by clicking on the “Proceed to next page” phrase 46 of the page of FIG. 4 without that information being entered, the system will alert the user to the error and prompt him to correct it.

The next page is shown on FIG. 6. This page bears the heading 50 “Consideration: Planned Payment,” a paragraph 52 with the heading 54 “Background” and the paragraph 56 with the heading 53 “Consideration Assessment Tool.” It also includes a paragraph 58 that takes the form of a table for the user to enter input data dividing the purchase price into categories of consideration. The price may include, for example, the payment of cash, the assumption of debt, the transfer of equity, and so on. The user proceeds to the next page by clicking on the “Proceed to next page” phrase 59.

The next page, shown in FIG. 7, bears the name 60 “Measuring Success” and includes table 61 entitled “Success Measurement Assessment Tool.” This table elicits input data about the metrics that the user will use to measure whether the proposed acquisition shall have been successful, and the certainty of the answers. These pages complete the information presented to the user and solicit the necessary information for the system to make preliminary recommendations.

The system makes these preliminary recommendations based upon decision trees established with the assistance of experts in the field that is the subject of the decision. In the example here, the decision tree is established with the help of accounting and business consulting experts. In practice, this is done by an iterative process to produce a “decision free” type algorithm. A trained individual begins by interviewing one or more experts in the field, and reducing their input to a schematic or narrative decision tree that covers the principal scenarios. One or more subsequent interviews then refines and elaborates upon the decision tree. The decision tree can be tested with actual or hypothetical input data with respect to which certain correct outputs are expected. If there is a discrepancy between the actual outputs of the system and the expected outputs, or a bug in obtaining outputs, the bugs or discrepancies can be corrected. Finally, the decision tree is translated into a computer language and programmed into the computer.

The preliminary recommendations are presented on the next page, shown in FIGS. 8A, 8B and 8C. It can be seen that the system has preliminarily recommended ten alternative arrangements for the proposed transaction, listed in a table 62 under the column 64 “Deal Structure.” The text under the next column 65 briefly describes each alternative under the last column 66. Note the applicability of each alternative may be a numerical ranking of the recommendations, a presentation of special issues for consideration, or other information. The user at this point in the process now has a general sense of some of the factors that dictate a structure for his transaction and a description of several alternative structures for his transaction. The next step is to refine the analysis.

Before proceeding to that next step, however, the user can change his input data to observe the resultant changes in the preliminary recommendations 70. This is done by going to the page hierarchy or module home page revisiting the pages to be changed, making the desired change, and returning to the Preliminary Recommendations page shown in FIGS. 8A, 8B and 8C. The change in input data can be either with respect to the substantive data itself or with respect to the degree of certainty attached to particular data. This is a very valuable way for the user to understand the importance and weight assigned to the factual scenario surrounding the proposed transaction.

The page hierarchy shown in FIG. 1 functions as a dynamic table of contents. When the user has entered sufficient input information and the system has processed that information sufficiently to develop some conclusions or preliminary output, the initial standard page hierarchy shown in FIG. 1 can be revised to so reflect. The revision can take the form of presenting a page hierarchy that outlines some of the topics that have been determined to be applicable in greater detail, or deleting others determined not to be applicable, or substituting a wholly different page hierarchy. The system thus incrementally receives necessary input information, processes that information, presents results of that processing, and sends additional information based on the results of the processing. Unlike some prior art systems the present system does not expand large amounts of processing power or consume large amounts of user time in inputting or processing all the information conceivably necessary to analyze a given topic; instead it receives input and processes that input incrementally to arrive at output that is narrow and tailored to the degree desired by the user.

The business combination submodule section of the module begins with the page hierarchy shown in FIGS. 9 a and 9 b, followed by the “Business Combination Accounting” page shown in FIG. 10. This page begins with a paragraph 71 having a short explanation of the point at issue and then two further paragraphs 72 and 73 outlining some of the accounting implication to the two approaches.

Numeric examples of the two accounting methods are available to the user by clicking on the “see numeric examples” phrase 82. That links to the page shown in FIG. 19 (see below). Additional information can be accessed concerning FASB rulings on the accounting issues by clicking on the “new FASB rulings” phrase 84 shown in FIG. 10. The user proceeds to the next page by clicking on the phrase “Which method applies to my situation” 86 shown in FIG. 10.

FIG. 11 shows the next page which describes the methods required for this section and which allows the user to click into the page after that by clicking on the “Proceed to next page” phrase 90.

That next page is shown in FIG. 12. Tables 92 and 94 on that page invite responses to two sets of questions designed to obtain facts necessary to the determination of whether the proposed transaction constitutes a business combination and the determination of the acquiring entity tool.

The determination of business combination states and the determination of the acquiring entity tool is done through a decision tree prepared with the assistance of expert professional or consulting firms. As in the case of certain other modules, this is an interactive process. A person trained in the system first interviews a professional in the topic at issue, such as a lawyer or a tax accountant in the case of a topic involving legal or tax implications. This initial interview is designed to produce the broad outlines of a decision algorithm or “decision tree.” It may be facilitated with the use of templates designed for producing decision algorithms or used in the past in similar decision algorithms. Once a preliminary decision algorithm is constructed, it can be refined and detailed by further interviews with the professional. After it is tentatively completed, it can be tested with the use of real or hypothetical data with respect to which the correct decision outcome is already known in order to determine whether there are discrepancies in the result or bugs in the processing. These can then be corrected, the algorithm retested, and the testing and correction procedure repeated until the system proves satisfactory. The algorithm is ultimately translated into computer code using a suitable computer language, and loaded into the system.

The algorithms used for processing and displaying data are conveniently categorized into several groups. There is computational logic which serves to process input data, versus presentation logic which serves to determine the screens, pages, sections, modules and submodules to be displayed. Within the category of computational logic are arithmetic logic and operations logic. Arithmetic logic is used to mathematically operate on input data that is in numeric form, typically to derive output data or intermediate data that also is in numeric form. The arithmetic logic is thus mathematical in nature. A simple example of arithmetic logic is an algorithm that computes profits by subtracting expenses and depreciation from revenue. Operations logic is used to operate on input data that is in non-numeric form, typically to derive output data or intermediate data that also is in non-numeric form. An example of operations logic is an algorithm that determines whether long-term capital gains treatment is available under the tax laws in connection with a transaction based upon input describing the nature of an asset that is the subject of the transaction.

The presentation logic in the system includes navigational logic and display logic. Navigational logic is used to determine which screens are displayed to a user based on the results of the computational logic. For example; if the computational logic determines that long term capital gains treatment is available under the tax laws for a particular transaction, then the navigational logic may present screens associated with that determination rather than screens associated with alternative determinations such as a determination that only short term capital gains treatment is available. The display logic determines the particular presentation of the screens identified by the navigational logic, i.e., the formatting issues.

Continuing with reference to the figures, if the system determination is that the proposed transaction is indeed a business combination, then clicking on the “Proceed to next page” phrase 98 accesses the page shown in FIG. 13 to determine whether the pooling method of accounting is available for the transaction. It can be seen that this page checks input data in three categories through the presentation of three tables of questions 102, 104 and 106.

If the system determination is that pooling is available, then clicking on the “Proceed to next page” phrase 108 will access the page shown in FIG. 14. The user can then assess the impact of the proposed acquisition or the company financial statements under a pooling accounting system, by inputting the answers to the questions presented on table 110.

Clicking on the “Proceed to next page” phrase 112 brings up the page shown in FIG. 15. The table 113 in this page shows pro forma financial statements under pooled accounting. Some of the data in this page will be the result of system calculations, while some will be simply the data input by the user in response to specific questions in the preceding pages, such as cash, net operating loss and the like. The pooling section is thus complete, and clicking on the “Back to main module” phrase 114 redirects the user to the page shown in FIGS. 8A, 8B and 8C.

The system may determine from the input data elicited up to and through the page shown in FIG. 13 that pooling is not available. In that event, upon clicking on the “Proceed to next page” phrase 108 in the page of FIG. 13, the user is directed to the page of FIG. 16 for application of the Purchase Method of Accounting. Acquiring companies typically desire the pooling method of accounting over the purchase method, and so this page leads with a list of the reasons 115 that pooling was determined to be unavailable in order of importance. This list allows the user to consider modifying the structure of the transaction, to address those reasons and inputting the data corresponding to the modified transaction in an effort to obtain pooling treatment. These reasons listed are unique to the data input and are derived from the algorithms created at the outset from the decision tree iterations.

The next paragraph explains that this page assists the user in analyzing the impact of the proposed transaction on the company's financial statement using the purchase method of accounting. The following table 116 requests input data in response to questions of concern to the purchase method accounting computations, and the user is then invited to access the next page.

The next page, shown in FIG. 17, shows on a table 118 the pro forma results of the proposed transaction or the financial statements of the acquiring company using the purchase method of accounting. Again, some of these numerical results are computed, while some are simply drawn from the input data. As in the case of the pooling method section, the user then returns to the non-module page shown in FIGS. 8A, 8B and 8C by checking on the “Back to main module” phrase 120.

FIG. 18 shows a page devoted to defining several terms used in the module for the convenience of the user. This page is accessed from the page shown in FIG. 1, the Module Home page. FIG. 19 shows a page devoted to an example of the pooling method versus the purchase method of accounting in a hypothetical acquisition, so that the user can see how the two methods compare correctly, which also is accessed from the Module Home page of FIG. 1. FIG. 20 shows an outline of appendices to this module describing certain additional ramifications of the outcome. This page is accessed through the page hierarchy of FIG. 9.

It can be appreciated from the above examples that the system is based upon the combination of several advantageous properties. It presents pure information to assist in educating the user about the matter under consideration. Moreover, this information is accessible at the points in the process where it is applicable. Thus, the system does not attempt to create an expert out of a non-expert all at once and at the outset. Rather, the system provides useful and practical information at the time the user needs to use it.

Further, the system is organized in such a way that the user can use only so much of it as desired. If the user is initially interested in a preliminary recommendation or set of recommendations, rather than a further refinement, that alone is available. If a user is interested in quickly seeing the effect or the recommendations of changing the input data, that is available. If a user wishes to use one module but not another, that is generally available.

The hierarchy of modules, submodules, sections, subsections and pages, and their interrelationship with the data elements and formulae is important. By making the completion of certain pages, or the entering of certain data, or the making of certain determinations by the system, preconditions to entering subsequent pages, the system ensures that the use of the system is tailored to the particular circumstances of the user. 

1-42. (canceled)
 43. Non-transitory computer-readable storage media encoded with a computer program including instructions executable by a processor to create a simulation application comprising: (a) a software module configured to present a scenario, wherein the scenario comprises one or more questions; (b) a software module configured to establish an algorithm, wherein the algorithm comprises a computational logic; (c) a software module configured to solicit from a user one or more responses to the one or more questions; (d) a software module configured to record the one or more responses and store the one or more responses in a database; (e) a software module configured to use the algorithm to analyze the one or more responses stored in the database; and (f) a software module configured to perform one or more of: evaluate the one or more responses, evaluate performance of the responses, repeat the steps (a) to (e), or finalize the simulation application.
 44. The media of claim 43, wherein the user is a management team or a manager.
 45. The media of claim 43, wherein the scenario comprises a problem comprising business management, accounting, financial investment, or engineering.
 46. The media of claim 43, wherein the one or more questions are arranged in a particular order.
 47. The media of claim 43, wherein the one or more questions are simultaneously presented.
 48. The media of claim 43, wherein the algorithm comprises computational logic for analyzing at least one response.
 49. The media of claim 48, wherein the computational logic includes arithmetic logic to mathematically operate on numerical components of at least one response.
 50. The media of claim 48, wherein the computational logic includes operation logic to infer a conclusion based on non-numerical components of at least one response.
 51. The media of claim 48, wherein the computational logic comprises navigational logic for selecting a next question based on an output of the computational logic.
 52. The media of claim 48, wherein at least one response evaluation is based on an output of the computational logic.
 53. The media of claim 43, wherein at least one response includes a degree of certainty and the degree of certainty is used to evaluate at least one response.
 54. The media of claim 43, wherein the application is offered as software as a service.
 55. A computer-implemented system comprising (a) a digital processing device comprising a memory device and an operating system configured to perform executable instructions; and (b) a computer program including instructions executable by the digital processing device to create a simulation application comprising: (1) a software module configured to present a scenario, wherein the scenario comprises one or more questions; (2) a software module configured to establish an algorithm, wherein the algorithm comprises a computational logic; (3) a software module configured to solicit from a user one or more responses to the one or more questions; (4) a software module configured to record the one or more responses and store the one or more responses in a database; (5) a software module configured to use the algorithm to analyze the one or more responses stored in the database; and (6) a software module configured to perform one or more of: evaluate the one or more responses, evaluate performance of the responses, repeat the steps (a) to (e), or finalize the simulation application.
 56. The system of claim 55, wherein the user comprises a management team or a manager.
 57. The system of claim 55, wherein the scenario comprises a problem related to business management, accounting, financial investment, or engineering.
 58. The system of claim 55, wherein the algorithm comprises computational logic for analyzing at least one response.
 59. The system of claim 58, wherein the computational logic includes arithmetic logic to mathematically operate on numerical components of at least one response.
 60. The system of claim 58, wherein the computational logic includes operation logic to infer a conclusion based on non-numerical components of at least one response.
 61. The system of claim 58, wherein the computational logic comprises navigational logic for selecting a next question based on an output of the computational logic.
 62. The system of claim 55, wherein at least one response includes a degree of certainty and the degree of certainty is used to evaluate at least one response. 